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REMARKS 

The Office action has been carefully considered. Claims 1-26 are now 
pending in this application. The Office action rejected claims 1-26, under 35 U.S.C. 
§ 103(a) as being unpatentable over U.S. Patent No. 6,185,733 B1 to Breslau 
("Breslau") in view of U.S. Patent No. 6,438,610 B1 to Pearson ("Pearson"). 
Further, the Office action rejected claims 1-12 under 35 U.S.C. § 1 12, second 
paragraph as being indefinite for failing to particularly point out and distinctly claim 
the subject matter which applicants regard as the invention. Applicants have, 
amended claims 1, 5, 10 and 12 to obviate the §1 12 rejection and respectfully 
disagree with §103 rejection. 

By present amendment, claims 1, 5, 10 and 12 have been amended. 
Applicants submit that the claims as filed were patentable over the prior art of 
record, and that the amendments herein are for purposes of clarifying the claims 
and/or for expediting allowance of the claims and not for reasons related to 
patentability. Reconsideration is respectfully requested. 

Prior to discussing reasons why applicants believe that the claims in this 
application are clearly allowable in view of the teachings of the cited and applied 
references, a brief overview of the present invention is presented. 

The present invention is directed to a system and method for facilitating 
communications between a client computing device and remote device. In general, 
client devices that do not have a large amount of local memory storage often need 
to request files or other data from another device that is remotely located on a 
network. As such, the request for the data, which is initiated by the client device in 
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a first format, often needs to be converted into a second format suitable for 
transmission and recognition on the network and remote device respectively. 
Further, once the data that corresponds to the request is returned from the remote 
computer, the data often needs to be reconverted back to the first format in order to 
be used properly by the client device. 

Thus, in one embodiment of the invention, a method in a client computing 
device connected to a remote server facilitates this exchange of data. The method 
comprises, generally, receiving a file system read request (a first format) at the 
client computing device, converting the file system read request to an access 
request (a second format) for the network, communicating the access request to 
the remote server, receiving data from the remote server in response to the access 
request, and reconverting the received data to correspond to the file system read 
request (back to the first format). Note that the above description is for example 
and informational purpose only and should not be used to interpret the claims, 
which are discussed below. 

Turning to the claims, independent claim 1 and dependent claims 2-12 have 
been rejected by the Office action as being unpatentable over Breslau in view of 
Pearson. Applicants respectfully disagree. 

In order to establish prima facie obviousness of a claimed invention, all of 
the claim limitations must be taught or suggested by the prior art. In re Royka, 490 
F.2d 981, 180 USPQ 580 (CCPA 1974). In addition, "all words in a claim must be 
considered in judging the patentability of that claim against the prior art." In re 
Wilson, 424 F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 1970). Further, if prior 
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art, in any material respect teaches away from the claimed invention, the art cannot 
be used to support an obviousness rejection. In re Geisler, 116 F.3d 1465, 1471, 
43 USPQ2d 1362, 1366 (Fed Cir. 1997). 

Claim 1, as amended, essentially recites a method that comprises receiving 
a file system read request at the client device, converting the file system read 
request to an access request of a remote transfer protocol, communicating the 
access request to the remote server having data corresponding to the file system 
read request maintained thereby, receiving data from the remote server in 
response to the access request, and reconverting the received data of the remote 
transfer protocol to correspond to the file system read request. 

Regarding the first recited element of claim 1 , the Office action contends 
that Breslau teaches receiving a file system read request at the client device. 
Column 1, lines 30-38, column 3 lines 47-49 and column 5, lines 7-14 of Breslau 
are cited by the Office action, which contends that the term "library definition 
statement" (as used in Breslau) has the same meaning as the term "file system 
read request" (as used in the present invention). 

Regarding the second recited element of claim 1 , the Office action contends 
that Breslau teaches converting the file system read request to an access request 
of a remote transfer protocol. Figures 3 and 5 and column 7, lines 37-65 of Breslau 
are cited by the Office action, which contends that the term "HTTP GET" (as used 
in Breslau) has the same meaning as the term "remote transfer protocol" (as used 
in the present invention). 
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Regarding the third and fourth recited elements in claim 1, the Office action 
contends that Breslau teaches communicating the access request to the remote 
server having data corresponding to the file system read request maintained 
thereby and receiving data from the remote server in response to the access 
request. Column 8, lines 16-28 and column 6, lines 12-20 of Breslau are cited. 

The Office action admits that Breslau does not specifically teach the fifth 
element recited in claim 1. More specifically, reconverting the received data of the 
remote transfer protocol to correspond to the file system read request is not taught 
by Breslau. However, the Office action contends that Pearson (at column 2, lines 
3-31) teaches this element. As such, the Office action concludes that it would have 
been obvious to a person skilled in the art at the time the invention was made to 
combine the teachings of Breslau and Pearson because Pearson's decompression 
would improve the capacity of Breslau's system by allowing the client to restore the 
original image. Applicants respectfully disagree with this conclusion. 

Breslau teaches, generally, a system having a linkage editor that is operable 
to access libraries of objects that are both local (i.e., objects that reside within the 
same computing platform as the linkage editor itself) and remote (i.e., objects that 
reside in a separate computing platform from the linkage editor but that are 
accessible over a network.) See column 2, lines 44-58 of Breslau. More 
specifically, when the linkage editor requests an object from a library that is remote, 
the library definition statement (alleged by the Office action to be a file system read 
request) will include two portions (which is different from a file system read request) 
to specify the location of the library, i.e., a subdirectory tree and a TCP/IP address. 
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That is, the library definition statement will specify the location of the computer on 
the network (TCP/IP address) and the location of the library (subdirectory) within 
the computer on the network. As such, when a library definition statement is 
generated, the library definition statement is interpreted to either be local (having 
no TCP/IP portion) or remote (having a TCP/IP portion), but the library definition 
statement remains unchanged (i.e., it is not converted into any other form.) 
Significantly, such a library definition statement is not a file system read request. 

Moreover, in direct contrast to the teachings of Breslau, claim 1 recites 
converting, as opposed to merely interpreting, the file system read request to an 
access request of a remote transfer protocol. That is, the file system read request, 
which is in a first format (operable to be used in a computer file system 
environment) is converted (actually changed) into an access request which is in a 
second format (operable to be used in a computer network environment). Thus, by 
converting the request to the second format, the data that is ultimately requested 
can be more readily communicated back to the client device over the network. 
Breslau neither teaches nor suggests converting a file system read request into an 
access request of a remote transfer protocol. 

Furthermore, because the system and method taught by Breslau does not 
convert the library definition statement, there is no need to reconvert the returned 
data from the remote source; (if anything Breslau teaches away from converting / 
reconverting). Thus, there is no motivation to take the teachings of Breslau and 
combine them with the teachings of Pearson because the system and method of 
Breslau accomplishes its objective without converting anything. That is, there is no 
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motivation to improve upon the teachings of Breslau by referencing Pearson 
because data returned in the system in Breslau is already in the format needed to 
be used. Applicants submit that it would not have been obvious to combine the 

! teachings of Breslau and Pearson to make obvious the recitations of claim 1 . 

i 
i 

For at least these reasons, applicants submit that claim 1 is patentable over 
the prior art of record. 

Claims 2-12 depend either directly or indirectly from claim 1 . Applicants 
further submit that claims 2-1 2 are also allowable for the additional patentable 
elements included in these claims. For example, claim 2 recites the method of 
claim 1 wherein the file system read request is converted to an HTTP byte range 
request. The Office action contends that Breslau teaches this recitation by 
disclosing HTTP protocol at column 5, lines 37-65. Applicants respectfully 
disagree and point out that using HTTP protocol after interpreting a library 
definition statement is not the same as converting a file system read request to an 
HTTP byte range request. Applicants submit that for at least this additional reason, 
claim 2 is allowable over the prior art of record. 

Turning to independent claim 13 and dependent claims 14-24, the Office 
action rejected these claims for the same reasons as given for the rejection of 
claims 1-12. Applicants respectfully disagree and once again point out that Breslau 
does not teach converting a block request format into a byte request format as 
recited in Claim 13. Claim 13 recites a system that comprises a file system driver 
configured to receive file system requests directed to a remotely located volume, 
and being further configured to determine file location information on the volume; a 
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block driver connected to the file system driver to receive block requests 
corresponding to file locations therefrom, and being configured to convert the block 
requests into byte range requests of a remote transfer protocol and communicate 
the byte range request to the remote server; and the block driver returning data 
corresponding to the byte range request to the file system driver for conversion to 
data that satisfies the file system request. In contrast to claim 13, the cited portions 
of Breslau instead disclose a linkage editor, rather than a file system driver. Unlike 
applicants' file system driver that receives file system requests, the linkage editor of 
Breslau interprets a library definition statement to resolve the TCP/IP address for 
the location of a requested object. Significantly, Breslau also fails to disclose a 
block driver configured to convert a block request into a byte range request of a 
remote transfer protocol as also recited in Claim 13. As discussed above, Breslau 
does not teach or suggest any such conversion in interpreting the library definition 
statement to resolve the location of an object. 

Further, as also pointed out above, there is no motivation to improve upon 
the teachings of Breslau because the system in Breslau already returns data in a 
format (the original format) suitable for use in the system therein. As such, 
applicants submit that claim 13 and dependent claims 14-24 are allowable for at 
least these reasons. 

Turning to independent claim 25 and dependent claim 26, the Office action 
again rejected these claims for the same reasons as given for the rejection of 
claims 1 and 15. Applicants respectfully disagree and submit that claims 25-26 are 
allowable for at least the reasons detailed above with respect to claims 1 . Claim 25 
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recites the limitations of receiving a file system request at a client device and 
generating a remote transfer protocol request based on the file system request. As 
discussed regarding claims 1 and 13, the Office action misinterprets the library 
definition statement of Breslau. Such a library definition statement is not a file 
system read request. Moreover, a remote transfer protocol request that is in one 
format is generated based upon a file system read request which is in another 
format. By generating the request in the remote transfer protocol format, the data 
that is ultimately requested can be more readily communicated back to the client 
device over the network. Breslau neither teaches nor suggests receiving a file 
system read request as discussed above. Nor does Breslau teach or suggest 
generating a remote transfer protocol request based on the file system request. 

The Office action also contends that Breslau teaches the remote transfer 
protocol request comprises an HTTP-based request as recited in dependent claim 
26. Applicants respectfully disagree and point out that using HTTP protocol after 
interpreting a library definition statement as disclosed in Breslau is not the same as 
generating an HTTP request based on a file system read request. Each and every 
one of these differences discussed is significant. 

For at least these reasons, applicants submit that all the claims are 
patentable over the prior art of record. Reconsideration and withdrawal of the 
rejections in the Office Action is respectfully requested, and timely allowance of this 
application is earnestly solicited. 
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CONCLUSION 

In view of the foregoing remarks, it is respectfully submitted that claims 1-26 
are patentable over the prior art of record, and that the application is good and 
proper form for allowance. A favorable action on the part of the Examiner is 
earnestly solicited. 

If in the opinion of the Examiner a telephone conference would expedite the 
prosecution of the subject application, the Examiner is invited to call the 
undersigned attorney at (425) 836-3030. 

Respectfully submitted, 



Albert S. Michalik, Reg/No. 37,395 
Attorney for Applicant 
Law Offices of Albert S. Michalik, PLLC 
704 - 228th Avenue NE, Suite 193 
Sammamish, WA 98074 
(425) 836-3030 
(425) 836-8957 (facsimile) 
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